home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jul 89 / W0086-Re[2] MPW Pascal bu-Jul89 < prev    next >
Encoding:
Text File  |  1989-08-22  |  2.2 KB  |  78 lines  |  [TEXT/GEOL]
  1. Item    6277888                         18-July-89        18:58
  2.  
  3. From:   ARBOGAST                        Peat Marwick, Chris Arbogast
  4.  
  5. To:     ROSENSTEIN1                     Rosenstein, Larry
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    re to re MPW Pascal bug
  10.  
  11. Larry,
  12.  
  13.     I would like to disagree.  You may be correct that this is not considered a
  14. bug in the compiler.  If that is so then I would argue that it is a bug in the
  15. language definition.
  16.  
  17. Using the same example…
  18.  
  19. PROCEDURE Test;
  20.   VAR aFoo:  TFoo;
  21.       aFoo2: TFoo;
  22. BEGIN
  23.   aFoo2 := TFoo(aFoo);
  24. END;
  25.  
  26. >In this case, you are casting aFoo even though it hasn't been initialized yet.
  27. >When debugging is turned on, a cast involving an object reference generates
  28. >code that checks the cast's validity.
  29.  
  30.     This check is unwarrented.  If that's what I want to do why can't I do it?
  31. At most I would expect a warning.  The case of new is just one example.  If my
  32. first use of an unitialized variable is initializing through the use of a VAR
  33. parameter like in the case of NEW(), why should I be prevented from doing this?
  34.  
  35.     A similar problem arises when one tries to use the Member() function.
  36. MacApp gets in the way by checking object disipline before calling member().
  37. This force the programmer to test for nil explicitly even though member() would
  38. ordinarily handle that case by returning false.
  39.  
  40.     ie., one must write
  41.         IF (aView <> Nil) & (member( aView, TMyView )) THEN …
  42.  
  43.     rather then just
  44.         IF member( aView, TMyView ) THEN …
  45.  
  46.     Why should a cast do any checking at all?  Often, the reason to the cast is
  47. being used in the first place is to avoid the type or range checking that would
  48. otherwise occur.
  49.  
  50.     I was amazed to find that the compiler actually generates different code
  51. depending on the way the cast is used.  For example
  52.  
  53. VAR
  54.     aFoo    : TFoo;
  55.     aBar    : TBar;
  56.  
  57. Begin
  58.     aFoo := some.valid.foo;
  59.  
  60.     IF case1 THEN
  61.         aBar := TBar( aFoo )    { case1 works fine }
  62.     ELSE
  63.         TFoo( aBar ) := aFoo;   { this case does not }
  64.  
  65. End;
  66.  
  67.     Maybe I am off the wall but it seems that both of these cases should
  68. generate the same code.  Just a MOVE.L instruction that copies aFoo into aBar.
  69.  
  70. Any comments?
  71.  
  72. Chris Arbogast
  73. Peat Marwick Main & Co.
  74.  
  75.  
  76.  
  77.  
  78.